|
|
|
|
|
|
|
Figure T5-6:
Differences between Windows 95/98 and Windows NT implementations of
API functions that use strings |
|
|
|
|
|
|
|
|
In the rest of this section, you'll find out why these rules exist, when it is safe to break them, what other options exist, and what's really going on behind the scenes. |
|
|
|
|
|
|
|
|
When a string parameter is specified in a Declare statement, Visual Basic creates a new BSTR, which it loads with a NULL-terminated ANSI copy of the string. This is one of the rare cases where a BSTR contains an ANSI string instead of a Unicode string. |
|
|
|
|
|
|
|
|
If you use the ByVal operator when passing the string, the BSTR pointer is passed to the API function. If you pass the string ByRef (the default), a pointer to a temporary pointer variable containing the BSTR pointer is passed to the API function. These cases are illustrated in Figure T5-7. |
|
|
|
|
|
|
|
|
Virtually every Win32 API expects a pointer to a NULL-terminated string as a parameter. That means you must pass the strings with the ByVal keyword. You will occasionally run into situations where a custom DLL expects a pointer to a BSTR passed by Visual Basic. Those are the only cases where you will leave off the ByVal keyword. |
|
|
|
|
|
|
|
|
Once the API function returns, Visual Basic copies the ANSI BSTR back into its internal Unicode format. |
|
|
|
|
|
